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(54) System and method of multiparty billing for web access 



(57) A system and method for billing one or more 
participating parties for client access to the internet is 
disclosed including the steps of identifying at least one 
of the one or more participating parties as being respon- 
sible for the billing, allocating a share of the billing to 
each responsible participating party based on a prede- 
termined function and computing a billing amount for 
each of the responsible participating parties based on a 
function of the share and a client bandwidth usage. 
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\ Description 

[0001] The present invention generally relates to the billing of accesses to the World Wide Web of the Internet and, 
more particularly, to a system for sharing of billing for accessing the World Wide Web among multiple parties involved 
5 in providing information services and/or conducting electronic commerce on the world Wide Web. 

[0002] While dictionary meanings are generally implied for the terms included herein, the following summary includes 
demonstrative definitions: 

Internet: The network of networks and gateways that use the TCP/IP suite of protocols. 

10 

Client: A computer which issues commands to the server which performs the task associated with the command. 

Server: Any computer that performs a task at the command of another computer. A Web server typically supports 
one or more clients. 

15 

Network protocols: Standard methods for machines to communicate with one another. The protocols indicate how 
data should be formatted for receipt and transmission across networks. Heterogeneous machines can communi- 
cate seamlessly over a network via standard protocols. Examples of standard Internet protocols include HTTP 
("Hypertext Transfer Protocol"), SMTP ("Simple Mail Transfer Protocol") and FTP ("File Transfer Protocol"). 

20 

world wide web (WWW or Web): The Internet's application that permits users seeking information on the Internet 
to switch from server to server and database to database by clicking on highlighted words or phrases of interest 
(hyperlinks). An Internet Web server supports clients and provides information. The Web can be considered as 
the Internet with ail of the resources addressed as Uniform Resource Locators (URLs) and which uses HTML (see 
25 below) to display the information corresponding to URLs and provide a point-and-click interface to other URLs. 

On the Web, "browsers" constitute client programs while the programs sending back information to the browser 
constitute server programs. 

Universal Resource Locator (URL) : A way to uniquely identify or address information on the Internet. Can be 
30 considered to be a Web document version of an e-mail address. URLs can be accessed with a Hyperlink. An 

example of a URL is "http://www.arun.com:80/table.htmr'. A URL has four components. Starting from the left, the 
first specifies the protocol to use, separated from the rest of the locator by a ":". Next is the hostname or IP address 
of the target host; this is delimited by the "//" on the left and on the right by a 7" or optionally a ":". The port number 
is optional, and is delimited on the left from the hostname by a ":" and on the right by a 7". The fourth component 
35 is the actual file name or program name. In this example, the ".html" extension means that this is an HTML file. 

HyperText Markup Language (HTML) : The language used by Web servers to create and connect documents that 
are viewed by Web clients. HTML uses Hypertext documents. 

40 Hypertext transfer protocol (HTTP) : An example of a stateless protocol, which means that every request from a 

client to a server is treated independently. The server has no record of previous connections. At the beginning of 
a URL, "http:" indicates the file contains hyperlinks. 

Internet Browser or web browser: A graphical interface tool that runs Internet protocols such as http, and displays 
45 results on the client's screen. The browser can act as an Internet tour guide, complete with pictorial desktops, 

directories and search tools used when a user "surfs" the Internet. In this application, the Web browser is a client 
service which communicates with the world wide Web. 

HTTP daemon (HTTPd): A Web Server having Hypertext Markup Language and Common Gateway Interface 
50 capability. The HTTPd is typically supported by an access agent which provides the hardware connections to 

machines on the intranet and access to the Internet, such as TCP/IP. 

[0003] For a user to access information or conduct electronic commerce on the world wide web, he/she typically 
uses a (client) computer to dial up through a phone line, cable or other means to the server computer of an on-line 
55 service provider (OLSP). The OLSP server computer is then connected to the Internet where the servers of content 
providers and merchants reside. Requests from the user and results from the content/merchant servers are all passed 
through the server computer of the OLSP. In providing the services for accessing the Web, the OLSP usually charges 
the user a service fee. 
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[0004] To charge users for accessing the Web, OLSPs generally adopt two popular billing methods. Users are 
charged either by a flat rate (e.g. $19.95 per month) or by connection time (e.g. $1 .95 per hour). However, there are 
shortcomings associated with these two billing approaches. One problem with the flat rate billing method is that it does 
not reflect users 1 prioritizations of Internet resources. Furthermore, this method does not encourage users to save 

5 Internet resources. As a result, heavy users of the Web can potentially monopolize part of the Internet resources, thus 
preventing others from accessing them. On the other hand, the connection time billing method is also unfair to the 
users who are continuously charged even though they may not receive any information from the Web due to waiting 
time caused by either network congestion or server unavailability. Indeed, as more and more people are "surfing" the 
Web, the network congestion problem is becoming more severe. Finally, these billing methods fail to provide a method 

10 of credit accumulation to offset fee payment for accessing the Web in order to attract Web traffic and improve the 
business value of the Internet. 

[0005] A flexible payment scheme is described in WENJIA FANG: 'Building an accounting infrastructure for the In- 
ternet' GLOBAL TELECOMMUNICATIONS CONFERENCE, 1996. GLOBECOM '96. 'COMMUNICATIONS: THE KEY 
TO GLOBAL PROSPERITY LONDON, UK 18-22 NOV 1996, NEW YORK, USA, IEEE, US, 18 November 1996 
15 (1996-11-28), pages 105-109, XP01220161 ISBN: 0-7803-3336-5. In this scheme, the payment associated with use 
of the internet may be the sender, receivers, or both. For example in the case of video-conferencing, the participants 
may choose to split the cost. 

[0006] An online service development tool with fee setting capabilities is described in WO 96/1 5505. The fee structure 
envisaged can handle both fees levied against users and third party content providers. 

20 [0007] In order to provide a billing method that is fairer to the user and that can also prevent heavy users from 
monopolizing part of the Internet resources, the OLSP should charge the user based on his/her actual usage. However, 
simple usage-based pricing may discourage the user from exploring the Web because he/she may be afraid of poten- 
tially large charges. Thus, there is a need for a better usage-based billing method that will encourage or entice the 
user to explore the Web, thus creating more business for the content providers/merchants and others in the electronic 

25 marketplace. There is also a need for a multiparty billable usage-based method (and system] for providing access to 
the World Wide Web of the Internet and sharing the accessing cost/credit. 

[0008] The present invention provides for a system and method for billing one or more participating parties for client 
access to the internet, comprising: means for identifying at least one of the one or more participating parties as being 
responsible for the billing, the identifying means including a means for identifying a hyperlink source and a hyperlink 

30 target for each access; means for allocating a share of the billing to each responsible participating party based on a 
predetermined function; and means for computing a billing amount for each of the responsible participating parties 
based on a function of the share, a client bandwidth usage, the hyperlink source and the hyperlink target. 
[0009] In a preferred system and method, the billing amount is further based on the time of day of the access. 
[0010] Preferably, a client session comprises a sequence of subsessions which are dynamically initiated and termi- 

35 nated by the client, each subsession having a duration and the billing amount is based on the duration of each sub- 
session. 

[001 1 ] It is also preferable for the system to track an actual size of a data transfer associated with a web page access 
and compute the billing amount of each responsible participating party as a function of the actual size. 
[001 2] The method of the present invention preferably includes the steps of identifying at least one of the responsible 
40 participating parties as receiving bonus credit and applying the bonus credit to offset any billing amount. The applying 
step is preferably based on a function of a hyperlink source web page. 

[0013] The tracking step of the invention preferably includes the step of analyzing access logs and referrer logs to 
identify each web access and corresponding actual size. 

[0014] The participating parties preferably include a client, an on-line service proxy server, one or more content 
45 provider servers and/or one or more advertisers. Free client access to localized object insertions by the on-line service 
proxy server is preferably provided. Clients are preferably identified based on a static IP address or a dynamic IP 
address. 

[0015] Each client's billing amount is preferably based on a function of a client service level such as real-time support, 
transmission speed, a content filtering requirement, and/or an advertisement selection requirement. 

50 [0016] In accordance with another aspect of the present invention, the system provides an indication, through a client 
interface on a source web page, whether a client will be responsible for payment of a billing amount for access to a 
target web page. This indication is preferably accomplished by presenting different appearances of object linkages 
indicating whether the client is responsible for the payment of a billing amount and indicating the billing amount to the 
client. The presentation of the appearances of the object linkages may be done through different coloring, special 

55 marks or different graphical representations. 

[0017] It is preferable that one of the participating parties is an on-line service proxy server which retrieves a rema- 
pped version of the source web page from its cache storage when a client request is received. Preferably, the remapped 
source web pages containing the object linkages are left intact without the need to prescan and analyze the content 
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* 

of the source web pages and the URL of the target web page is maintained. 

[001 8] Finally, it is preferable to arrange the on-line service proxy servers hierarchically and the objects on the source 
web pages are remapped by each proxy server to indicate whether the client is one of the responsible participating 
parties, the remapped objects are stored in the hierarchically arranged on-line service provider proxy servers according 
5 to the geographic connection to the subject matter of the objects so that the remapping of objects is localized at each 
proxy server and the same original URL for each remapped object is maintained. 

[0019] This invention presents a usage-based system and method for an OLSP or other party to share Web access 
billings among multiple participating parties involved in a web network computer system. These participating parties 
may include OLSPs, content providers/merchants, advertisers and users. A novel billing method that allows credit 

10 accumulation to offset payments is preferably provided to track accurate web usage through standard web logging 
mechanisms. Web pages can be used to display billing responsibility of the users for accessing the Web. Users, as a 
result, have more power to decide which content and/or commercial advertisements they want to access. The present 
invention offers not only the combined capabilities regular telephone, 1-800, 1-900, prime time, non-prime time, mobile 
phone, pay-per-view billing, but also capabilities of dynamic, real-time, interactive, unscheduled, subsession, usage- 

15 based and multiparty sharing features for Web access billings. 

[0020] While, in telephone billing, the concept of 800 and 900 numbers has been used to differentiate the billing 
parties, this is done based on connection time or flat fee. Although, for cable TV, the pay-per-view method is charged 
on a user session basis to the viewer, only a single party, the viewer, is responsible for the billing. Finally, while cellular 
phone systems are also user session-oriented with both the caller and the receiver sharing the bill, the billable parties 

20 do not change dynamically once a call session is initiated and the splitting of the bill follows a prespecified convention 
and is based on connection time. 

[0021] The present invention also differs from the traditional on-line service model like America On-line or Prodigy 
where the service provider acts like a middle man to collect the bill from the subscribers and then redistribute the 
income among different content providers. There, the access providers divide the billing of the access costs of users 

25 among multiple parties and bill each party on its share of the costs. In the present invention, the focus is on collecting 
from multiple parties instead of redistributing among multiple parties. In addition, the payment to a content provider/ 
merchant in the traditional on-line service provider model is based on the number of subscribers the on-line service 
provider lines up, while the present invention is based on the actual usage by the users or subscribers. 
[0022] Embodiments of the invention will now be described, by way of example only, with reference to the accom- 

30 panying drawings in which: 

Fig. 1 is a schematic diagram of a data processing system in accordance with the present invention; 

Fig. 2a is a flow diagram of a preferred embodiment of the multiparty usage-based billing method of the present 
35 invention; 

Fig. 2b is a more detailed flow diagram of step 203 of the method of Fig. 2a; 

Fig. 3a is a diagram of different appearances of a hypertext page in accordance with a preferred embodiment of 
40 the present invention; and 

Fig. 3b is a flow diagram of a method according to another preferred embodiment of the present invention. 

[0023] In Fig. 1 , a graphical representation of a network computer system 1 1 which may be utilized to implement the 
45 present invention is depicted. Network computer system 1 1 includes one or more content provider (or merchant) servers 
4 and an on-line service provider (OLSP) proxy server 5 connected via an Internet network 3. The servers communicate 
with each other following specific protocols known in the art, such as HTTP and TCP/IP. Those skilled in the art will 
appreciate that there are a multitude of variations available to create the Internet connection between the servers. In 
order to provide payment/credit among different parties, a credit provider server 10 may also be connected to the 
50 network 3. The credit provider server 10 performs credit verification for the content provider server 4 and the OLSP 
proxy server 5, computes the net payment among the different parties and provides for payment of the respective bills. 
[0024] Each content provider server 4 is preferably a stateless hypertext server system that provides services to a 
plurality of client computers 1. An example of such a system is a World Wide Web server which includes a central 
processing unit 6, main memory 7 and disk drive 8. The server 4 stores hypertext objects, such as HTML files, graphical 
55 icon files (e.g. GIF files), audio, video objects and CGI programs, on its local disk 8 and provides these objects to 
various clients using HTTP through the Internet 3. Each client computer 1 is a personal computer or workstation as is 
known to those skilled the art and preferably incorporates a software browser, such as the Netscape Navigator offered 
by Netscape Communications, Inc., to retrieve and display hypertext objects through the OLSP proxy server 5. 
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[0025] According to an embodiment of the present invention, a client computer 1 dials up with a modem (not shown) 
over either a cable or telephone line 2 to connect to the OLSP proxy server 5. Through the OLSP proxy server 5, the 
users of the client computers can access hypertext objects stored on the content provider servers 4. In order to speed 
up the retrieval process, the OLSP proxy server 5 may cache some of the hypertext objects on its own local disk 8 
5 using caching algorithms generally known in the art. If a client computer 1 requests objects which have been cached, 
the OLSP proxy server 5 returns the cached objects to the client computer 1. If not available locally, then the OLSP 
proxy server 5 forwards the request on behalf of the client computer 1 to the destination content provider server 4 and 
sends the results back to the client computer 1 once the requested objects are retrieved from the disk drive 8 of the 
content provider server 4. 

io [0026] Therefore, the OLSP proxy server 5 retrieves hypertext objects from storage on content provider servers 4 
or from its own hypertext object store cached on disk 8 and sends back the results to the client computers 1 . The 
hypertext object store can be in the form of a file system or a database system. The hypertext objects are typically 
stored in nonvolatile storage and can be retrieved into main memory when requested. 

[0027] The proxy server 5, which is also a kind of hypertext server, uses a conventional HTTPd to process requests 
15 from client computers 1 . An example of an HTTPd is the Internet Connection Server, sold by IBM. For each hypertext 
request that is processed, the proxy server 5 logs certain information about the request in a request log located in its 
main memory 7. An agent program can be used to retrieve the hypertext request log from the main memory 7, convert 
the data into a format readable by the system of the present invention and store the fields and records in a hypertext 
object request log data base in disk drive 8. The hypertext object request log data base can be spooled to large capacity 
20 storage devices, such as tapes, periodically for backup purposes and to free up space in disk drive 8. 

[0028] The usage-based multiparty billing logic 9 of the present invention is preferably embodied as computer read- 
able program code stored on disk drive 8 of the proxy server 5. Alternatively, it may be stored on other conventional 
magnetic media such as a diskette or optical media such as a CD-ROM. The billing logic 9 can also be stored on the 
content provider servers 4 to permit verification or negotiation of payments with the OLSP. Those skilled in the art will 
25 appreciate that the billing logic 9 also can be stored solely on the content provider server in an environment lacking a 
proxy server and function as described hereinbelow. 

[0029] In Internet accesses through a web browser, each web page access constitutes a subsession and clicking of 
a HTTP link controls the termination of the previous and the initiation of the next subsession. According to the present 
invention, billing is based on the bandwidth (actual) usage by the client of the page accessed. 

30 [0030] According to a web server logging mechanism, for each hypertext object access, a plurality of information 
about the access is recorded, including the requester address, the hyperlink source (i.e., the hypertext object that 
refers the client to the target object), the hyperlink target (i.e., the hypertext object being accessed) and the time stamp 
of the access. The hyperlink source and hyperlink target form a hyperlink access pair (V_currenLstop, V_next_stop), 
representing a step in the user traversal path on the hypertext objects. The hyperlink access pair represents a decision 

35 and an action by a Web user, denoted as user_id, to move from the current URL, denoted by V_current_stop, to the 
next URL, denoted by V_next_stop. To link alt access pairs between when a user logs in and when the user logs out 
from the OLSP proxy server, a traversal path P (useMd, session_id_s) can be formed. A traversal path can be defined 
as (V_login_stop_0, V_stop_1 , V_stop_2, ... VJogout_stop_n), indicating all the hypertext objects visited by the user 
during that login session identified by sessionJd_s. Once a traversal path P(user_id, session jd_s) is identified, the 

40 billable events related to the login session can be calculated. 

[0031] According to the present invention, other parties may share the bill with the user. To illustrate, the URL page 
denoted by V_current_stop, the original content provider may be willing to absorb the accessing cost for the user if the 
page is an advertisement. Similarly, the OLSP may be willing to share part of the cost (in a form of discount to the user) 
because the content page may have previously been locally cached. To permit this bill sharing, a hyperlink access pair 

45 HAP(user_id, sessionjd, hapjd) = (V_current_stop, V_next_stop) is mapped into a set of payments denoted by Pay 
(HAP) = (pay(userjd), pay(OLSP_id), pay(advertiseMd), pay(contentprovider_n), ...etc.} which identifies ail parties 
involved in sharing the payment for that particular access pair and computes the apportioned payments. The final total 
payment to and from each party is computed by adding together the payments for all the access pairs. 
[0032] The payment formula among the parties involved can be defined based on a specific business model. Those 

so skilled in the art will appreciate that various billing methods are possible based on the logs provided by the OLSP proxy 
server 5. 

[0033] For each session, two or more sub-sessions SS, each consisting of (user_id, sessionjd, hap_id, 
sub_session_id), can be defined. The sub-session SS contains a set of parameters that can be tracked based on the 
proxy server logs. The parameters applicable to billing may include: 

55 

• the requester address, 

• hyperlink source, 

• hyperlink target, 
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• time stamp of the access, 

• message size, and 

• transfer status. 

5 [0034] The requester address is the network address (IP address) of the user's client computer. Hypertext objects 
are usually accessed through hyperlinks embedded in another hypertext object, such as an HTML file displayed on 
the browser that the user employs. As discussed hereinabove, the hyperlink target, as denoted by V_next_stop, is the 
requested object or page and the hyperlink source, as denoted by V_current_stop, is the object or page which refers 
to (exposes) the target. Both hyperlink source and hyperlink target are typically represented by a universal resource 

10 identifier (URI) or universal resource locator (URL) in HTTP and, as described, they together form a hyperlink access 
pair. The time stamp is the time when the requested hypertext object is processed and sent back from the proxy server. 
[0035] In order to bill the user (and/or other participating parties) based on actual usage, the hyperlink access pair, 
time stamp, URL transfer status and transfer message size are used. Because the hyperlink target indicates the location 
of the content requested, the billing formula can identify the target content provider as being responsible for payment. 

15 Also, because the hyperlink source indicates the present URL content, the billing formula can identify the source content 
provider as being responsible for payment. Because the time stamp indicates the time that the Web server processes 
the request, the billing formula can be a function of the connection time, peak time, off-peak time, etc. Finally, because 
the URL transfer status and the transfer message size indicate the actual network bandwidth that is used by the client, 
the billing formula can be based substantially on the actual network bandwidth usage. 

20 [0036] The following are two log entries from separate logs recording a particular request to an OLSP proxy server 
5. An access log records information about a page access (or "hit"). A referrer log records information about the page 
which referred the client to the accessed page. 
192.168.1.26 - - [01/Oct/1996:08:10:20 +0600] "POST 
/cgi-in/db2www/col_login.d2w/report HTTP/1 .0" 200 2544 

25 [0037] The text above depicts a typical access log entry created by a proxy server in response to a client request. 
The information includes inter alia: 

• the requester address: 192.168.1 .26 

• hyperlink target: /cgi-in/db2www/coljogin.d2w/report 
30 • time stamp of the access: 01/Oct/1 996:08:1 0:20 

• URL message transferred size: 2544 

• URL transfer status: 200. 

[01 /Oct/1 996:08: 10:20 +0600] 
35 ,, http://colds.col.watson.ibm.com:2080/cgi-bin/db2www/col_login.d2w/input M 

[0038] The text above depicts a typical referrer log entry created by a proxy server in response to the client request. 
The information includes, inter alia: 

• hyperlink source address: colds.col.watson.ibm.com 
40 • time stamp of the access: 01 /Oct/1 996:08: 10:20. 

[0039] These two log entries indicate that a user login request 

/cgi-bin/db2www/col_login.d2w/input from IP address 192.168.1 .26 to hyperlink target address colds.col.watson.ibm. 
com through tcp port 2080 was made and that on 01/Oct/1 996:08:1 0:20, a 2544 bytes login report response /cgi-in/ 
45 db2www/col_login.d2w/report were transferred to client IP address 192.168.1 .26 successfully. 
[0040] The hyperlink source colds.col.watson.ibm.com 

:2080/cgi-bin/db2www/col_login.d2w/input and the hyperlink target colds.col.watson.ibm.com :2080/cgi-bin/db2www/ 

col_login.d2w/report together form a hyperlink access pair represented by (V_current_stop, V_next_stop), where 

V_current_stop = colds.col.watson.ibm.com 
so :2080/cgi-bin/db2www/col_login.d2w/input represents a login screen that the user viewed. After the user logged in and 

clicked the submit button, the login request was transferred to the server colds.col.watson.ibm.com through tcp port 

2080. The response URL represented by V_next_stop = coids.col.watson.ibm.com:2080/cgi-bin/db2www/coljogin. 

d2w/report was transferred back to the client computer. 

[0041] The following are referrer log entries for a user login session: 
55 [01/Oct/1996:08:10:20+0600] 

n http://colds.col.watson.ibm.com:2080/cgi-bin/db2www/coLlogin.d2w/input B 

[01 /Oct/1 996:08: 10:23 +0600] 

n http://colds.col.watson.ibm.com:2080/cgi-bin/db2www/colJogin.d2w/report B 



EP 0 891 062 B1 



[01/Oct/1996:08:10:57 +0600] 

B http^/coldsxol.watsonJbm.com:2080/cgj-bin/db2www/col _pc_add.d2w/inpuf 

[01/Oct/1996:08:10:59 +0600] 

"http://colds.col.watson.ibm.com:2080/cgi-bin^ 
5 [0042] The following are access log entries for the same user login session: 

192.168.1.26 - - {01/0ct/1 996:08:1 0:20 +0600] TOST 

/cgi-bin/db2www/col_Iogin.d2w/report HTTP/1 .0 B 200 2544 

192.168.1.26 - - [01/Oct/1 996:08: 10:23 +0600] TOST 

/cgi-bin/db2www/col_pc_add.d2w/input HTTP/1 .0* 200 2918 
10 192.168.1.26 - - [01 /Oct/1 996:08: 10:57 +0600] TOST 

/cgi-bin/db2www/col_pc_add.d2w/report HTTP/1 .0" 200 2433 

192.168.1.26 - - [01 /Oct/1 996:08: 10:59 +0600] TOST 

/cgi-bin/db2www/colJogoff .d2w/report HTTP/1 .0* 200 2928. 

[0043] The corresponding traversal path P(useMd, session_id_s) can be computed as (colJogin.d2w/input, 
15 col_login.d2w/report, 

col_pc_add.d2w/input, coLpc_add.d2w/report, colJogoff.d2w/report). This traversal path indicates all the hypertext 
objects visited by the user during that login session identified by session_id_s. These terms mean: 

• col_login.d2w/input: user login submitted 
20 • co!Jogin.d2w/report: user login approved 

• coLpc_add.d2w/input: user requested a pc component 

• col_pc_add.d2w/report: user pc component request approved 

• coljogoff.d2w/report: user logoff submitted. 

25 [0044] The following table describes the usage records for a user with IP address 1 92.1 68.1 .26. A network bandwidth- 
based usage can be derived from this table. As can be seen, a total of 10823 bytes were transferred successfully to 
the user with IP address 192.168.1.26. 



30 



IP address 


Time Stamp 


Target Object 


Target 
Size 


Transfer 
Status 


192.168.1.26 


01 /Oct/1 996:08: 10:20 


col_login.d2w/report 


2544 


200 


192.168.1.26 


01 /Oct/1 996:08: 10:23 


coLpc_add.d2w/input 


2918 


200 


192.168.1.26 


01 /Oct/1 996:08: 10:57 


col_pc_add.d2w/report 


2433 


200 


192.168.1.26 


01 /Oct/1 996:08: 10:59 


col_logoff.d2w/report 


2928 


200 






total transfer size 


10823 





[0045] The following table shows a possible scenario for sharing the usage billing among the user, OLSP and PC 
component advertiser. Here, the OLSP pays for the login and logoff screen transfer, the advertiser pays for the page 
transferred for the user's purchase of a pc component, and the user pays none or even gets a bonus from the OLSP 
who may in turn get a bonus from the advertiser because the OLSP enabled this business transaction. 



Events 


Time Stamp 


User 


OLSP 


Advertiser 






Paid 


Paid 


Paid 


colJogin.d2w/report 


01/Oct/1 996:08:10:20 


bonus 


2544 




col_pc_add.d2w/input 


01/Oct/1996:08:10:23 






2918 


col_pc_add.d2w/report 


01/Oct/1996:08:10:57 




bonus 


2433 


colJogoff.d2w/report 






2928 





[0046] The following table shows a multiparty billing method with peak and off-peak time capability. This example 
assumes the start time of the peak hour is 08:10:30. So the OLSP will pay 2544 bytes in non-prime time rate and 2928 
bytes in prime time rate. The advertiser will pay 291 8 bytes in non-prime time rate, 2433 bytes in prime time rate, plus 
some bonus to the OLSP. 
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Events 


Time Stamp 


User 


OLSP 


Advertiser 


Prime 






Paid 


Paid 


Paid 


Time 


colJogin.d2w/report 


01/Oct/1996:08:10:20 




2544 




no 


col_pc_add.d2w/input 


01/Oct/1996:08:10:23 




bonus 


2918 


no 


coLpc_add.d2w/report 


01/Oct/1 996:08:1 0:57 




bonus 


2433 


yes 


col_logoff.d2w/report 


01 /Oct/1 996:08: 10:59 




2928 




yes 



[0047] The following table shows a scenario for sharing the usage billing among the user, OLSP and the PC com- 
ponent advertiser when part of the transfer was unsuccessful. Here, the OLSP will pay for the part of the bill corre- 
sponding to the unsuccessful transfer event. 



Events 


Time Stamp 


User 
Paid 


OLSP 
Paid 


Advertiser 
Paid 


Transfer 
Status 


colJogin.d2w/report 


01/Oct/1996:08:10:20 




2544 




good 


col_pc_add.d2w/ 
input 


01/Oct/1996:08:10:23 






2918 


good 


col_pc_add.d2w/ 
report 


01 /Oct/1 996:08: 10:57 




2433 no bonus 




bad 


coljogoff.d2w/report 


01 /Oct/1 996:08: 10:59 




2928 




good 



25 

[0048] To describe the billing algorithm, the following data formats for the relevant fields are shown for the proxy 
server log tables, including the referrer log table and the access log table. The referrer log table has the following fields: 

• hyperlink source server URL (SURL) : varchar(32-bit) (e.g. colds.watson.ibm.com/cgi-bin/db2www/col_login.d2w/ 
30 input) 

• time stamp of the access (TS): dd/mm/yr:hr:min:sec (e.g. 01/oct/1996:08:10:20). 
[0049] The access log table has the following fields: 

35 • the customer IP address (CIP) : IP1 .IP2.IP3.IP4: integer 

• hyperlink target server URL (TURL): varchar(32-bit) (e.g. http://colds.watson.ibm.com/cgi-bin/db2www/colJogin. 
d2w/report) 

• time stamp of the access (TS): dd/mm/yr:hr:min:sec 

• RL message transferred size (MS): integer 
40 • URL transfer status: integer (MTS): integer. 

[0050] The following is a database view created based on the above two log tables. This view will be referred to for 
the following billing algorithm: 



CACNO 


CIP 


TS 


SURL 


TURL 


MS 


MTS 



CACNO stands for customer account number. 

[0051] Figure 2a shows the flow diagram of a preferred embodiment of the multiparty usage-based billing method 
according to the present invention. This method implements the usage-based multiparty billing logic 9 stored as shown 
in Fig 1. In each billing cycle (e.g. a month), all the log records described hereinabove which have been stored during 
the cycle are processed to compute the total bill for all the parties responsible for payment. In step 201 , the billing logic 
determines if there are still log records that need to be processed. If so, the next log record is retrieved in step 202. 
For each log record, all the parties responsible for payment and all the parties entitled to receive bonus credit for the 
corresponding web page access are identified in step 203. 

[0052] Figure 2b is a more detailed flow diagram of step 203 of Fig. 2a. In step 210, a determination is made whether 
the customer IP address (CIP) is static or dynamic. For example, dial-in lines typically use dynamic IP addresses 
whereas leased lines use assigned static IP addresses. The OLSP can identify whether a CIP, which is stored in log 



r 
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data, is static or dynamic. If the IP address is determined to be static, the IP address is directly mapped to a customer 
account number (CACNO) in step 211 . If the IP address is determined to be dynamic, a DHCP (dynamic host config- 
uration protocol) program can resolve the dynamic IP mapping via a unique identifier to a CACNO in step 212. In step 
213, the parties who are paying the bill are identified. This can be accomplished, based on the particular billing function 
5 (Pay(HAP)), by ascertaining the target URL (TURL) contained in the access log. In step 214, the parties entitled to 
receive bonus points are identified. Similarly this can be accomplished, based on the particular billing function (Pay 
(HAP)), by ascertaining the source URL (SURL) contained in the referrer log. 

[0053] Continuing in Fig. 2a, after all the parties involved are identified, payment and bonus credit are calculated for 
each party in step 204 based on a prespecified function (e.g. Pay(HAP)) of the transferred message size (MS) of the 

10 log record. The calculation of payment or bonus credit is executed only if the message transfer status (MTS) is suc- 
cessful. Otherwise, no payment will be charged nor bonus credited to any of the parties. Depending on the time stamp 
(TS), different pricing can be applied for the same message size. For example, a 2 MB message may cost 20 cents 
during the daytime but may cost only 10 cents during the nighttime. Different pricing can also be applied based on the 
duration of each subsession. Because the log data in the access and referrer logs contain sufficient information to 

15 identify user sessions, each consisting of a sequence of subsessions, the duration of a subsession represents the time 
period between two consecutive user requests. Since requests are initiated dynamically by a user based on real-time 
interactions, the duration of any subsession is controllable by the user. Furthermore, based on the client profile, different 
pricing can also be applied according to different service levels such as transmission speed (e.g. pay more for high 
speed communication), real-time support (e.g. stock quotes), content filtering (e.g. specification of content to be re- 

20 ceived) and advertisement receipt selection (e.g. no advertisements). After all the log records are processed, then the 
total bill for each customer and for any other party responsible for payment is calculated in step 205, taking into account 
any bonus credited to them. 

[0054] If the cost for an access may be shared by multiple parties, it is preferable to indicate, on the object linked to 
the web page to be accessed, whether the user is responsible for payment of a portion of the access bill and, if yes, 

25 his/her share of the charge. This provides an incentive to users to access more web pages on the internet. This dis- 
tinctive indication can be accomplished via creating different appearances of object linkages through coloring, special 
marks or graphical representations as explained below with respect to Fig. 3a. For example, an image of an adver- 
tisement can be modified to add the information about the billing parties and the modified image can be stored (cached) 
in disk device 8 at the OLSP proxy server 5. When the web page containing the advertisement is displayed by the web 

30 browser on a client computer, the advertisement image will be requested from the proxy server 5. The proxy server 5, 
upon receiving the request for the image, returns the locally cached modified image containing the billing information. 
In the preferred embodiment, the web page containing the advertisement image is not changed. Therefore, there is 
no requirement of prescanning or analyzing the web pages and altering their content. Only the advertisement image 
files are being changed. This can be achieved by substituting the image file with another one having the same URL, 

35 but with the billing information added. Since the modified image files are stored at the proxy server, the OLSP can 
manage the splitting of access charges among the user and any other participating parties based on the source web 
page and the destination (target) of the HTTP link associated with each advertisement image file. 
[0055] Figure 3a shows a diagram of different appearances of a hypertext page which allow the proxy server to 
indicate whether the viewer of the page or another party is responsible for payment. A hypertext page A.html 301 

40 contains an advertisement linking to an IBM web page. The advertisement image is a gif file called a.gif 302. When a 
user at client computer 1 requests page A.html 301 , the proxy server 5 can request this page from the content provider 
4 or it can fetch the page from its cache in disk drive 8. Further, when the proxy server 5 sends page A.html 301 to the 
client computer 1 , it can also send the modified image a.gif 303 from its cache in disk drive 8. The appearance of a. 
gif 303 will be different from a.gif 302. For instance, in Fig. 3a, a.gif 302 indicates to the user that the IBM page will be 

45 free of charge if the user clicks on this advertisement. The party which is responsible for payment can be recorded 
elsewhere in the proxy server and charged for the payment during the bill processing step 203 in Figure 2a. As noted 
above, the different appearances of the cached hypertext objects can be highlighted through different coloring, special 
marks or graphical representations. Note again that for an HTML-based web page A.html 301 , the replacement of a. 
gif 302 by a.gif 303 does not require prescanning and analyzing the content of the web page A.html. It can simply be 

so accomplished by fetching the a.gif 303 from the proxy server instead of obtaining a.gif 302 from the content provider. 
No change is needed to the object linkage in A.html 301 , since the file name is still a.gif, only with a different appearance. 
[0056] Any party responsible for payment can send a set of gif files to the proxy server. These gif files are then used 
to remap original gif files when requested by a user. In accordance with the present invention, the payment can be 
shared by all parties involved, including the on-line service provider, the content provider, the user and the advertiser. 

55 The proxy server can also provide a different service level by eliminating all advertisements from a hypertext page for 
a user. Namely, the proxy server 5 can eliminate a.gif 303 from A.html 301 by not sending a.gif 303 to the client computer 
1. 

[0057] Fig. 3b is a flow diagram of a method according to a preferred embodiment of the present invention for rem- 
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apping objects to indicate billing responsibility. This method permits the deployment of a hierarchical set of proxy 
servers, where the remapping of objects can be localized and the same original name (URL) for a remapped object 
can be used. For example, car dealers in the area of White Plains, NY and Orlando, FL belonging to a single car 
dealership chain can together place advertisements on a national content provider's web page. The dealers will send 

5 separate localized advertisement gif files to their respective local OLSPs. In step 31 0, the OSLP stores the remapped 
objects in its multiple proxy servers. In step 311, when users access the content provider's web page exposing the 
advertisement, the advertisement will be remapped to an advertisement with localized appearance by the respective 
local OLSP. In step 312, the original URL for a remapped object is the same regardless of the particular OLSP from 
which a user accessed the object. When a user clicks on a page containing an advertisement gif file, the OLSP then 

10 selects the localized version of the gif file for display by the user's browser. In this manner, the car dealers can have 
local customers viewing their advertisement and will have billing responsibility for the accesses by their local customers 
only. 

[0058] While certain embodiments of the present invention have been described hereinabove various modifications 
and improvements will occur to those skilled in the art. Thus, it should be understood that the preferred embodiment 
15 has been provided as an example and not as a limitation. The scope of the invention is defined only by the appended 
claims. 

Claims 

20 

1. A computer system (5) for billing one or more participating parties for client access to the internet, comprising: 

means for identifying at least one of the one or more participating parties as being responsible for the billing; 

25 means (9) for allocating a share of the billing to each responsible participating party based on a redetermined 

function; 

characterized by further comprising: 

30 means for computing a billing amount for each of the responsible participating parties based on a function of 

the share, a client bandwidth usage, the hyperlink source and the hyperlink target 

the identifying means including a means for identifying a hyperlink source and a hyperlink target for each 
access. 

35 2. The system of claim 1 wherein the means for computing a billing amount comprises a means for computing the 
billing amount based on a time of day of the access. 

3. The system of claim 1 wherein the means for computing the billing amount comprises means for computing the 
billing amount for a client session comprising a sequence of subsessions which are dynamically initiated and 

40 terminated by the client. 

4. The system of claim 3 wherein each subsession has a duration and the hyperlink source and the hyperlink target 
means for computing the billing amount is based on the duration of each subsession. 

45 5. The system of claim 1 wherein the means for computing the billing amount comprises a means for tracking an 
actual size of a data transfer associated with a web page access and a means for computing the billing amount 
of each responsible participating party as a function of the actual size. 

6. The system of claim 1 further comprising: 

50 

means for identifying at least one of the responsible participating parties to receive bonus credit; and 

means for applying the bonus credit to offset any billing amount. 

55 7. The system of claim 6 wherein said means for applying the bonus credit comprises a means for identifying a 
function of a hyperlink source web page. 

8. The system of claim 5 wherein said means for tracking comprises means for analyzing access logs and referrer 
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logs to identify each web access and corresponding actual size. 

9. The system of claim 1 wherein the participating parties include a client, an on-line service proxy server, one or 
more content provider servers and/or one or more advertisers. 

5 

10. The system of claim 9 wherein the means for identifying comprises means for providing free client access to 
localized object insertions by the on-line proxy server. 

11. The system of claim 1 wherein the means for identifying comprises means for identifying clients based on a static 
to IP address or a dynamic IP address. 

12. The system of claim 1 wherein said means for computing comprises means for computing a client billing amount 
based on a function of a client service level. 

15 13. The system of claim 12 wherein the function is based on real-time support, transmission speed, a content filtering 
requirement, and/or an advertisement selection requirement. 

14. The system of claim 1 further comprising a means for indicating, through a client interface on a source web page, 
whether a client will be responsible for payment of a billing amount for access to a target web page. 

20 

15. The system of claim 14 wherein the means for indicating comprises means for presenting different appearances 
of object linkages indicating whether the client is responsible for the payment of a billing amount and indicating 
the billing amount. 

25 16. The system of claim 15 wherein the means for presenting comprises means for presenting the appearances of 
the object linkages through different coloring. 

17. The system of claim 15 wherein the means for presenting comprises means for presenting the appearances of 
the object linkages through special marks. 

30 

18. The system of claim 15 wherein the means for presenting comprises means for presenting the appearances of 
the object linkages through different graphical representations. 

19. The system of claim 15 wherein one of the participating parties is an on-line service proxy server and the presenting 
35 step comprises the step of retrieving a remapped version of the source web page from a cache of the on-line 

sen/ice proxy server. 

20. The system of claim 19 wherein the remapped source web pages containing the object linkages are left intact 
without the need to prescan and analyze the content of the source web pages and the URL of the target web page 

40 is maintained. 

21. The system of claim 15, further comprising: 

means for remapping objects on the source web pages to indicate whether the client is one of the responsible 
45 participating parties; 

means for storing the remapped objects in a plurality of hierarchically arranged on-line service provider proxy 
servers; 

so means for localizing the remapping of objects at each proxy server; and 

means for maintaining the same original URL for a remapped object. 



55 Patentanspruche 



1 . Rechnersystem (5), das dazu dient, einem oder mehreren Teilnehmern fur den Zugriff eines Client auf das Internet 
Gebuhren in Rechnung zu stellen, wobei das Rechnersystem Folgendes umfasst: 
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Mittel, um mindestens einen des einen Oder der mehreren Teilnehmer als zahlungspflichtig anzugeben; 

Mittel (9), um jedem zahlungspflichtigen Teilnehmer auf der Grundlage einer vorher festgelegten Funktion 
einen Teil der in Rechnung gestellten Gebuhren zuzuweisen; 

5 

dadurch gekennzeichnet, dass es des weiteren Folgendes umfasst: 

Mittel, um fur jeden der zahlungspflichtigen Teilnehmer in Abhangigkeit von dem Anteil, der Bandbreitennut- 
zung eines Client, der Hyperlink-Quelle und dem Hyperlink-Ziel einen Rechnungsbetrag zu berechnen; 

w 

wobei das Angabemittel ein Mittel zur Feststellung einer Hyperlink-Quelle und eines Hyperlink-Ziels fur jeden 
Zugriff enthalt. 

2. System nach Anspruch 1 , wobei das Mittel zur Berechnung eines Rechnungsbetrags ein Mittel umfasst, um den 
15 Rechnungsbetrag auf der Grundlage der Uhrzeit des Zugriffs zu berechnen. 

3. System nach Anspruch 1 , wobei das Mittel zur Berechnung des Rechnungsbetrags Mittel umfasst, um den Rech- 
nungsbetrag fur eine Client-Sitzung zu berechnen, die eine Folge von Teilsitzungen umfasst, welche von dem 
Client dynamisch gestartet und beendet werden. 

20 

4. System nach Anspruch 3, wobei jede Teilsitzung eine bestimmte Dauer hat und das Mittel in Form der Hyperlink- 
Quelle und des Hyperlink-Ziels zur Berechnung des Rechnungsbetrags auf der Dauer einer jeden Teilsitzung be- 
ruht. 

25 5. System nach Anspruch 1 , wobei das Mittel zur Berechnung des Rechnungsbetrags ein Mittel umfasst, um den 
tatsachlichen Umfang einer Datenubertragung in Verbindung mit einem Zugriff auf eine Webseite zu erfassen, 
sowie ein Mittel, um den Rechnungsbetrag eines jeden zahlungspflichtigen Teilnehmers in Abhangigkeit von dem 
tatsachlichen Umfang der Datenubertragung zu berechnen. 

30 6. System nach Anspruch 1 , das des Weiteren Folgendes umfasst: 

Mittel, um mindestens einen der zahlungspflichtigen Teilnehmer als einen Teilnehmer anzugeben, der ein 
Bonusguthaben erhalt; und 

35 Mittel, um das Bonusguthaben zur Verrechnung mit dem Rechnungsbetrag zu verwenden. 

7. System nach Anspruch 6, wobei das Mittel zur Verwendung des Bonusguthabens ein Mittel umfasst, das dazu 
dient, eine Funktion einer Webseite anzugeben, die eine Hyperlink-Quelle enthalt. 

40 8. System nach Anspruch 5, wobei das Mittel zur Erfassung Mittel umfasst, um Zugriffsprotokolle und Verweissei- 
tenprotokolle auszuwerten, um jeden Webzugriff und den entsprechenden tatsachlichen Umfang der Datenuber- 
tragung festzustellen. 

9. System nach Anspruch 1 , wobei zu den Teilnehmern ein Client, ein Onlinedienst-Proxyserver, ein oder mehrere 
45 Server von Inhalteanbietern und/oder ein oder mehrere Werbungtreibende gehoren. 

10. System nach Anspruch 9, wobei das Mittel zur Feststellung Mittel umfasst, um durch den Online-Proxyserver einen 
freien Client-Zugriff auf Objekt-Einfugungen zu ermoglichen, die den ortlichen Gegebenheiten angepasst wurden. 

50 11. System nach Anspruch 1 , wobei das Mittel zur Feststellung Mittel umfasst, die dazu dienen, Clients auf der Grund- 
lage einer statischen IP-Adresse Oder einer dynamischen IP-Adresse festzustellen. 

12. System nach Anspruch 1 , wobei das Mittel zur Berechnung Mittel umfasst, um den Rechnungsbetrag eines Client 
in Abhangigkeit von der Dienstebene des Client zu berechnen. 

55 

13. System nach Anspruch 12, wobei die Funktion auf der Echtzeitunterstiitzung, der Ubertragungsgeschwindigkeit, 
dem Erfordernis der Filterung des Inhalts und/oder dem Erfordernis der Auswahl der Werbeanzeigen beruht. 
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14. System nach Anspruch 1 , das des Weiteren ein Mittel umfasst, urn uber eine Client-Schnittstelle auf einer Quel- 
lenwebseite anzugeben, ob ein Client zur Zahlung eines Rechnungsbetrags fur den Zugriff auf eine Zielwebseite 
verpflichtet ist. 

5 15. System nach Anspruch 14, wobei das Mittel zur Angabe Mittel umfasst, urn verschiedene Erscheinungsformen 
von Objektverknupfungen darzustellen, die angeben, ob der Client zur Zahlung eines Rechnungsbetrags verpflich- 
tet ist, und die die Hohe des Rechnungsbetrags angeben. 

16. System nach Anspruch 15, wobei das Mittel zur Darstellung Mittel umfasst, urn die Erscheinungsformen der Ob- 
10 jektverknupfungen durch eine unterschiedliche Farbgebung darzustellen. 

17. System nach Anspruch 15, wobei das Mittel zur Darstellung Mittel umfasst, urn die Erscheinungsformen der Ob- 
jektverknupfungen durch spezielle Markierungen darzustellen. 

is 18. System nach Anspruch 15, wobei das Mittel zur Darstellung Mittel umfasst, um die Erscheinungsformen der Ob- 
jektverknupfungen durch verschiedene grafische Darstellungen darzustellen. 

19. System nach Anspruch 15, wobei einer der Teilnehmer ein Onlinedienst-Proxyserver ist und der Schritt der Dar- 
stellung den Schritt des Abrufs einer neu abgebildeten Version der Quellenwebseite aus einem Cachespeicher 

20 des Onlinedienst-Proxyservers umfasst. 

20. System nach Anspruch 1 9, wobei die neu abgebildeten Quellenwebseiten, die die Objektverknupfungen enthalten, 
intakt bleiben, ohne dass der Inhalt der Quellenwebseiten vorab abgefragt und ausgewertet werden muss, und 
die URL der Zielwebseite beibehalten wird. 

25 

21. System nach Anspruch 15, das des Weiteren Folgendes umfasst: 

Mittel, um Objekte auf den Quellenwebseiten neu abzubilden, um anzugeben, ob der Client einer der zah- 
lungspflichtigen Teilnehmer ist; 

30 

Mittel, um die neu abgebildeten Objekte in einer Vielzahl von hierarchisch angeordneten Proxyservern von 
Onlinedienstanbietern zu speichern; 

Mittel, um die Neuabbildung von Objekten auf jedem Proxyserver an die ortlichen Gegebenheiten anzupassen; 
35 und 

Mittel, um dieselbe ursprungliche URL fur ein neu abgebildetes Objekt beizubehalten. 
40 Revendications 

1 . Un systeme d'ordinateur (5), pour la facturation d'une ou plusieurs parties participantes concernant un acc§s client 
a I'lnternet, comprenant : 

45 des moyens, pour identifier au moins Tune des une ou plusieurs parties participantes comme £tant respon- 

sables pour la facturation ; 

des moyens (9), pour allouer un partage de la facturation & chaque partie participate responsable, en se 
basant sur une fonction pr6d6termin§e, 

50 

caracterise par le fait de comprendre en outre : 

des moyens, pour calculer une quantity de facturation pour chacune des parties participantes responsables, 
en se basant sur une fonction du partage, un usage de la largeur de bande par le client, la source hyperlien 
55 et la cible hyperlien ; 

les moyens ^identification comprenant des moyens pour identifier une source hyperlien et une cible hyperlien, 
pour chaque acc6s. 



EP 0 891 062 B1 

2. Le systeme selon la revendication 1 , dans lequel les moyens de calcul d'une quantity de facturation comprennent 
des moyens pour calculer ta quantity de facturation, en se basant sur I'heure du jour de l'acc§s. 

3. Le systeme selon la revendication 1 , dans lequel les moyens pour calculer la quantite de facturation comprennent 
5 des moyens pour calculer la quantite de facturation pour une cession client, comprenant une succession de sous- 
cessions, lancees dynamiquement et achevees par le client. 

4. Le systeme selon la revendication 3, dans lequel chaque sous-cession ptesente une certaine duree et les moyens 
tenant compte de la source hyperlien et de la cible hyperlien, pour calculer la quantite de facturation, sont bases 

w sur la dur6e de chaque sous-cession. 

5. Le systeme selon la revendication 1, dans lequel les moyens permettant de calculer la quantite de facturation 
comprennent des moyens pour suivre une tailie reelle du transfert de donnees, assocte k un acces a une page 
Web, et des moyens pour calculer la quantite de facturation de chaque partie participante responsable, en fonction 

15 de la taille reelle. 

6. Le systeme selon la revendication 1 , comprenant en outre : 

des moyens, pour identifier au moins Tune des parties participantes responsables, afin de recevoir un credit 
20 en bonus ; et 

des moyens, pour appliquer le credit en bonus, pour compenser une quantite de facturation eventuelle. 

7. Le systeme selon la revendication 6, dans lequel lesdits moyens duplication du credit de bonus comprennent 
25 des moyens pour identifier une fonction d'une page Web de source hyperlien. 

8. Le systeme selon la revendication 5, dans lequel lesdits moyens de poursuite comprennent des moyens pour 
analyser les journaux d'accds et les journaux de referencement, afin d'identifier chaque acces au Web et la taille 
reelle correspondante. 

30 

9. Le systeme selon la revendication 1 , dans lequel les parties participantes comprennent un client, un serveur man- 
dataire de service en ligne, un ou plusieurs serveurs de fournisseur de contenu et/ou un ou plusieurs annonceurs 
publicitaires. 

35 1 o. Le systeme selon la revendication 9, dans lequel les moyens pour identifier comprennent des moyens pour fournir 
un acces client libre a des insertions d'objets localises par le serveur mandataire en ligne. 

1 1. Le systeme selon la revendication 1 , dans lequel les moyens d'identification comprennent des moyens pour iden- 
tifier des clients en se basant sur une adresse IP statique, ou une adresse IP dynamique. 

40 

1 2. Le systeme selon la revendication 1 , dans lequel lesdits moyens de calcul comprennent des moyens pour calculer 
une quantite de facturation client en se basant sur une fonction d'un niveau de service offert au client. 

13. Le systeme selon la revendication 12, dans lequel la fonction est bas^e sur un support temps reel, une vitesse de 
45 transmission, une exigence de filtrage du contenu et/ou une exigence de selection des annonces publicitaires. 

14. Le systeme selon la revendication 1 , comprenant en outre des moyens pour indiquer, par une interface client sur 
une page Web source, si le client va etre responsable du paiement d'une quantite de facturation concernant I'accfcs 
a une page Web cible. 

50 

15. Le systeme selon la revendication 14, dans lequel les moyens dedication comprennent des moyens pour pre- 
senter differents aspects de liens objet, indiquant si le client est responsable du paiement d'une quantite de fac- 
turation et indiquant quelle est la quantite de facturation. 

55 16. Le systeme selon la revendication 1 5, dans lequel les moyens de presentation comprennent des moyens de pre- 
sentation des aspects des liens objet, par utilisation d'un coloriage different. 

17. Le systeme selon la revendication 15, dans lequel les moyens de presentation comprennent des moyens pour 
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presenter les apparences des liens objet, par Tintermddiaire de marques speciales. 

18. Le systeme seion la revendication 15, dans lequel les moyens de presentation comprennent des moyens pour 
presenter les aspects des liens objet par I'intermgdiaire de differentes representations graphiques. 

19. Le systdme selon la revendication 15, dans lequel Tune des parties participantes est un serveur mandataire de 
service en ligne, et l'6tape de presentation comprend l'6tape de recuperation d'une version remapp^e de la page 
Web source, depuis une antem£moire du serveur mandataire de service en ligne. 

20. Le systeme selon la revendication 19, dans lequel les pages Web source remapp^es contenant les liens objet 
sont laissees intact, sans devoir pr^-explorer et analyser le contenu des pages Web source, et I'URL de la page 
Web cible est conserve. 

21. Le systeme selon la revendication 15, comprenant en outre : 

des moyens, pour remapper des objets sur les pages Web source, afin d'indiquer si le client est Tune des 
parties participantes responsables ; 

des moyens, pour stocker les objets remapp^s en une plurality de serveurs mandataires fournis par des ser- 
vices en ligne agenc^s hi^rarchiquement ; 

des moyens, pour localiser le remappage d'objets h chaque serveur mandataire ; et 
des moyens pour conserver la meme URL d'origine, pour un objet remapp6. 
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